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 [28/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc2034.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc2034.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc2034.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc2034.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,340 @@
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: RFC 2034 Innosoft
+Category: Standards Track October 1996
+
+
+ SMTP Service Extension for
+ Returning Enhanced Error 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. Abstract
+
+ This memo defines an extension to the SMTP service [RFC-821, RFC-
+ 1869] whereby an SMTP server augments its responses with the enhanced
+ mail system status codes defined in RFC 1893. These codes can then
+ be used to provide more informative explanations of error conditions,
+ especially in the context of the delivery status notifications format
+ defined in RFC 1894.
+
+2. Introduction
+
+ Although SMTP is widely and robustly deployed, various extensions
+ have been requested by parts of the Internet community. In
+ particular, in the modern, international, and multilingual Internet a
+ need exists to assign codes to specific error conditions that can be
+ translated into different languages. RFC 1893 defines such a set of
+ status codes and RFC 1894 defines a mechanism to send such coded
+ material to users. However, in many cases the agent creating the RFC
+ 1894 delivery status notification is doing so in response to errors
+ it received from a remote SMTP server.
+
+ As such, remote servers need a mechanism for embedding enhanced
+ status codes in their responses as well as a way to indicate to a
+ client when they are in fact doing this. This memo uses the SMTP
+ extension mechanism described in RFC 1869 to define such a mechanism.
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 1]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+3. Framework for the Enhanced Error Statuses Extension
+
+ The enhanced error statuses transport extension is laid out as
+ follows:
+
+ (1) the name of the SMTP service extension defined here is
+ Enhanced-Status-Codes;
+
+ (2) the EHLO keyword value associated with the extension is
+ ENHANCEDSTATUSCODES;
+
+ (3) no parameter is used with the ENHANCEDSTATUSCODES EHLO
+ keyword;
+
+ (4) the text part of all 2xx, 4xx, and 5xx SMTP responses
+ other than the initial greeting and any response to
+ HELO or EHLO are prefaced with a status code as defined
+ in RFC 1893. This status code is always followed by one
+ or more spaces.
+
+ (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.
+
+4. The Enhanced-Status-Codes service extension
+
+ Servers supporting the Enhanced-Status-Codes extension must preface
+ the text part of almost all response lines with a status code. As in
+ RFC 1893, the syntax of these status codes is given by the ABNF:
+
+ status-code ::= class "." subject "." detail
+ class ::= "2" / "4" / "5"
+ subject ::= 1*3digit
+ detail ::= 1*3digit
+
+ These codes must appear in all 2xx, 4xx, and 5xx response lines other
+ than initial greeting and any response to HELO or EHLO. Note that 3xx
+ responses are NOT included in this list.
+
+ All status codes returned by the server must agree with the primary
+ response code, that is, a 2xx response must incorporate a 2.X.X code,
+ a 4xx response must incorporate a 4.X.X code, and a 5xx response must
+ incorporate a 5.X.X code.
+
+
+
+
+
+Freed Standards Track [Page 2]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ When responses are continued across multiple lines the same status
+ code must appear at the beginning of the text in each line of the
+ response.
+
+ Servers supporting this extension must attach enhanced status codes
+ to their responses regardless of whether or not EHLO is employed by
+ the client.
+
+5. Status Codes and Negotiation
+
+ This specification does not provide a means for clients to request
+ that status codes be returned or that they not be returned; a
+ compliant server includes these codes in the responses it sends
+ regardless of whether or not the client expects them. This is
+ somewhat different from most other SMTP extensions, where generally
+ speaking a client must specifically make a request before the
+ extended server behaves any differently than an unextended server.
+ The omission of client negotiation in this case is entirely
+ intentional: Given the generally poor state of SMTP server error code
+ implementation it is felt that any step taken towards more
+ comprehensible error codes is something that all clients, extended or
+ not, should benefit from.
+
+ IMPORTANT NOTE: The use of this approach in this extension should be
+ seen as a very special case. It MUST NOT be taken as a license for
+ future SMTP extensions to dramatically change the nature of SMTP
+ client-server interaction without proper announcement from the server
+ and a corresponding enabling command from the client.
+
+6. Usage Example
+
+ The following dialogue illustrates the use of enhanced status codes
+ by a server:
+
+ 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 ENHANCEDSTATUSCODES
+ C: MAIL FROM:<ne...@ymir.claremont.edu>
+ S: 250 2.1.0 Originator <ne...@ymir.claremont.edu> ok
+ C: RCPT TO:<mr...@dbc.mtview.ca.us>
+ S: 250 2.1.5 Recipient <mr...@dbc.mtview.ca.us> ok
+ C: RCPT TO:<no...@dbc.mtview.ca.us>
+ S: 550 5.1.1 Mailbox "nosuchuser" does not exist
+ C: RCPT TO:<re...@isi.edu>
+ S: 551-5.7.1 Forwarding to remote hosts disabled
+
+
+
+Freed Standards Track [Page 3]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ S: 551 5.7.1 Select another host to act as your forwarder
+ C: DATA
+ S: 354 Send message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 2.6.0 Message accepted
+ C: QUIT
+ S: 221 2.0.0 Goodbye
+
+ The client that receives these responses might then send a
+ nondelivery notification of the general form:
+
+ Date: Mon, 11 Mar 1996 09:21:47 -0400
+ From: Mail Delivery Subsystem <ma...@ymir.claremont.edu>
+ Subject: Returned mail
+ To: <ne...@ymir.claremont.edu>
+ MIME-Version: 1.0
+ Content-Type: multipart/report; report-type=delivery-status;
+ boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: text/plain; charset=us-ascii
+
+ ----- Mail was successfully relayed to
+ the following addresses -----
+
+ <mr...@dbc.mtview.ca.us>
+
+ ----- The following addresses had delivery problems -----
+ <no...@dbc.mtview.ca.us>
+ (Mailbox "nosuchuser" does not exist)
+ <re...@isi.edu>
+ (Forwarding to remote hosts disabled)
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: message/delivery-status
+
+ Reporting-MTA: dns; ymir.claremont.edu
+
+ Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
+ Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
+ Action: relayed
+ Status: 2.1.5 (Destination address valid)
+ Diagnostic-Code: smtp;
+ 250 Recipient <mr...@dbc.mtview.ca.us> ok
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+
+
+
+
+Freed Standards Track [Page 4]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+ Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+ Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+ Action: failed
+ Status: 5.1.1 (Bad destination mailbox address)
+ Diagnostic-Code: smtp;
+ 550 Mailbox "nosuchuser" does not exist
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+ Original-Recipient: rfc822;remoteuser@isi.edu
+ Final-Recipient: rfc822;remoteuser@isi.edu
+ Action: failed
+ Status: 5.7.1 (Delivery not authorized, message refused)
+ Diagnostic-Code: smtp;
+ 551 Forwarding to remote hosts disabled
+ Select another host to act as your forwarder
+ Remote-MTA: dns; dbc.mtview.ca.us
+
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU
+ content-type: message/rfc822
+
+ [original message goes here]
+ --JAA13167.773673707/YMIR.CLAREMONT.EDU--
+
+ Note that in order to reduce clutter the reporting MTA has omitted
+ enhanced status code information from the diagnostic-code fields it
+ has generated.
+
+7. Security Considerations
+
+ Additional detail in server responses axiomatically provides
+ additional information about the server. It is conceivable that
+ additional information of this sort may be of assistance in
+ circumventing server security. The advantages of provides additional
+ information must always be weighed against the security implications
+ of doing so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 5]
+
+RFC 2034 SMTP Enhanced Error Codes October 1996
+
+
+8. References
+
+ [RFC-821]
+ Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+ August, 1982. (August, 1982).
+
+ [RFC-1869]
+ Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed,
+ N., "SMTP Service Extensions", RFC 1869, November, 1995.
+
+ [RFC-1893]
+ Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
+ 1893, January, 1996.
+
+ [RFC-1894]
+ Moore, K., Vaudreuil, G., "An Extensible Message Format
+ for Delivery Status Notifications", RFC 1894, January,
+ 1996.
+
+9. Author Address
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+ tel: +1 818 919 3600 fax: +1 818 919 3614
+ email: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 6]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc2034.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc2142.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc2142.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc2142.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc2142.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,338 @@
+
+
+
+
+
+Network Working Group D. Crocker
+Request for Comments: 2142 Internet Mail Consortium
+Cateogry: Standards Track May 1997
+
+
+ MAILBOX NAMES FOR
+ COMMON SERVICES, ROLES AND FUNCTIONS
+
+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 specification enumerates and describes Internet mail addresses
+ (mailbox name @ host reference) to be used when contacting personnel
+ at an organization. Mailbox names are provided for both operations
+ and business functions. Additional mailbox names and aliases are not
+ prohibited, but organizations which support email exchanges with the
+ Internet are encouraged to support AT LEAST each mailbox name for
+ which the associated function exists within the organization.
+
+1. RATIONALE AND SCOPE
+
+ Various Internet documents have specified mailbox names to be used
+ when reaching the operators of the new service; for example, [RFC822
+ 6.3, C.6] requires the presence of a <PO...@domain> mailbox name
+ on all hosts that have an SMTP server. Other protocols have defacto
+ standards for well known mailbox names, such as <US...@domain> for
+ NNTP (see [RFC977]), and <WE...@domain> for HTTP (see [HTTP]).
+ Defacto standards also exist for well known mailbox names which have
+ nothing to do with a particular protocol, e.g., <AB...@domain> and
+ <TR...@domain>.
+
+ The purpose of this memo is to aggregate and specify the basic set of
+ mailbox names which organizations need to support. Most
+ organizations do not need to support the full set of mailbox names
+ defined here, since not every organization will implement the all of
+ the associated services. However, if a given service is offerred,
+ then the associated mailbox name(es) must be supported, resulting in
+ delivery to a recipient appropriate for the referenced service or
+ role.
+
+
+
+
+
+Crocker Standards Track [Page 1]
+
+RFC 2142 Mailbox Names May 1997
+
+
+ If a host is not configured to accept mail directly, but it
+ implements a service for which this specification defines a mailbox
+ name, that host must have an MX RR set (see [RFC974]) and the mail
+ exchangers specified by this RR set must recognize the referenced
+ host's domain name as "local" for the purpose of accepting mail bound
+ for the defined mailbox name. Note that this is true even if the
+ advertised domain name is not the same as the host's domain name; for
+ example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it
+ advertises the domain name VIX.COM in its "Path:" headers, then mail
+ must be deliverable to both <US...@VIX.COM> and
+ <US...@DATA.RAMONA.VIX.COM>, even though these addresses might be
+ delivered to different final destinations.
+
+ The scope of a well known mailbox name is its domain name. Servers
+ accepting mail on behalf of a domain must accept and correctly
+ process mailbox names for that domain, even if the server, itself,
+ does not support the associated service. So, for example, if an NNTP
+ server advertises the organization's top level domain in "Path:"
+ headers (see [RFC977]) the mail exchangers for that top level domain
+ must accept mail to <US...@domain> even if the mail exchanger hosts
+ do not, themselves, serve the NNTP protocol.
+
+2. INVARIANTS
+
+ For well known names that are not related to specific protocols, only
+ the organization's top level domain name are required to be valid.
+ For example, if an Internet service provider's domain name is
+ COMPANY.COM, then the <AB...@COMPANY.COM> address must be valid and
+ supported, even though the customers whose activity generates
+ complaints use hosts with more specific domain names like
+ SHELL1.COMPANY.COM. Note, however, that it is valid and encouraged
+ to support mailbox names for sub-domains, as appropriate.
+
+ Mailbox names must be recognized independent of character case. For
+ example, POSTMASTER, postmaster, Postmaster, PostMaster, and even
+ PoStMaStEr are to be treated the same, with delivery to the same
+ mailbox.
+
+ Implementations of these well known names need to take account of the
+ expectations of the senders who will use them. Sending back an
+ automatic mail acknowledgement is usually helpful (though we suggest
+ caution against the possibility of "duelling mail robots" and the
+ resulting mail loops).
+
+
+
+
+
+
+
+
+Crocker Standards Track [Page 2]
+
+RFC 2142 Mailbox Names May 1997
+
+
+3. BUSINESS-RELATED MAILBOX NAMES
+
+ These names are related to an organization's line-of-business
+ activities. The INFO name is often tied to an autoresponder, with a
+ range of standard files available.
+
+ MAILBOX AREA USAGE
+ ----------- ---------------- ---------------------------
+ INFO Marketing Packaged information about the
+ organization, products, and/or
+ services, as appropriate
+ MARKETING Marketing Product marketing and
+ marketing communications
+ SALES Sales Product purchase information
+ SUPPORT Customer Service Problems with product or
+ service
+
+
+4. NETWORK OPERATIONS MAILBOX NAMES
+
+ Operations addresses are intended to provide recourse for customers,
+ providers and others who are experiencing difficulties with the
+ organization's Internet service.
+
+ MAILBOX AREA USAGE
+ ----------- ---------------- ---------------------------
+ ABUSE Customer Relations Inappropriate public behaviour
+ NOC Network Operations Network infrastructure
+ SECURITY Network Security Security bulletins or queries
+
+
+5. SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
+
+ For major Internet protocol services, there is a mailbox defined for
+ receiving queries and reports. (Synonyms are included, here, due to
+ their extensive installed base.)
+
+ MAILBOX SERVICE SPECIFICATIONS
+ ----------- ---------------- ---------------------------
+ POSTMASTER SMTP [RFC821], [RFC822]
+ HOSTMASTER DNS [RFC1033-RFC1035]
+ USENET NNTP [RFC977]
+ NEWS NNTP Synonym for USENET
+ WEBMASTER HTTP [RFC 2068]
+ WWW HTTP Synonym for WEBMASTER
+ UUCP UUCP [RFC976]
+ FTP FTP [RFC959]
+
+
+
+
+Crocker Standards Track [Page 3]
+
+RFC 2142 Mailbox Names May 1997
+
+
+6. MAILING LIST ADMINISTRATION MAILBOX
+
+ Mailing lists have an administrative mailbox name to which add/drop
+ requests and other meta-queries can be sent.
+
+ For a mailing list whose submission mailbox name is:
+
+ <LI...@DOMAIN>
+
+ there MUST be the administrative mailbox name:
+
+ <LI...@DOMAIN>
+
+ Distribution List management software, such as MajorDomo and
+ Listserv, also have a single mailbox name associated with the
+ software on that system -- usually the name of the software -- rather
+ than a particular list on that system. Use of such mailbox names
+ requires participants to know the type of list software employed at
+ the site. This is problematic. Consequently:
+
+ LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,
+ INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE
+ MAILBOX NAMES.
+
+7. DOMAIN NAME SERVICE ADMINISTRATION MAILBOX
+
+ In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
+ Authority record (SOA RR) has a field for specifying the mailbox name
+ of the zone's administrator.
+
+ This field must be a simple word without metacharacters (such as "%"
+ or "!" or "::"), and a mail alias should be used on the relevant mail
+ exchanger hosts to direct zone administration mail to the appropriate
+ mailbox.
+
+ For simplicity and regularity, it is strongly recommended that the
+ well known mailbox name HOSTMASTER always be used
+ <HO...@domain>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker Standards Track [Page 4]
+
+RFC 2142 Mailbox Names May 1997
+
+
+8. AUTONOMOUS SYSTEM MAILBOX
+
+ Several Internet registries implement mailing lists for Autonomous
+ System contacts. So, for example, mail sent to <AS...@RA.NET> will
+ at the time of this writing reach the technical contact for
+ Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and
+ [RFC1656]).
+
+ Not all Autonomous Systems are registered with all registries,
+ however, and so undeliverable mailbox names under this scheme should
+ be treated as an inconvenience rather than as an error or a standards
+ violation.
+
+9. SECURITY CONSIDERATIONS
+
+ Denial of service attacks (flooding a mailbox with junk) will be
+ easier after this document becomes a standard, since more systems
+ will support the same set of mailbox names.
+
+10. REFERENCES
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, Information Sciences Institute, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the format of ARPA Internet text
+ messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
+ STD 9, RFC 959, Information Sciences Institute, October 1985.
+
+ [RFC974] Partridge, C., "Mail routing and the domain system", STD 14,
+ RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
+
+ [RFC976] Horton, M., "UUCP mail interchange format standard", RFC
+ 976, Bell Laboratories, February 1986.
+
+ [RFC977] Kantor, B., et al, "Network News Transfer Protocol: A
+ Proposed Standard for the Stream-Based Transmission of News", RFC
+ 977, University of California, February 1986.
+
+ [RFC1033] Lottor, M., "Domain administrators operations guide", RFC
+ 1033, SRI International, November 1987.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
+
+
+
+
+
+
+Crocker Standards Track [Page 5]
+
+RFC 2142 Mailbox Names May 1997
+
+
+ [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
+ November 1987.
+
+ [RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",
+ RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.
+
+ [RFC1655] Rekhter, Y., et al, "Application of the Border Gateway
+ Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM
+ Corp., July 1994.
+
+ [RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
+ Implementation Experience", RFC 1656, cisco Systems, July 1994.
+
+ [HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --
+ HTTP/1.0", RFC 1945, May 1996.
+
+11. ACKNOWLEDGEMENTS
+
+ This specification derived from an earlier draft written by Paul
+ Vixie. Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D.
+ Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and
+ Ed Morin for their comments on that draft.
+
+12. AUTHOR'S ADDRESS
+
+ Dave Crocker
+ Internet Mail Consortium
+ 127 Segre Ave.
+ Santa Cruz, CA
+
+ Phone: +1 408 246 8253
+ EMail: dcrocker@imc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker Standards Track [Page 6]
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc2142.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc2197.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc2197.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc2197.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc2197.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,452 @@
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: 2197 Innosoft
+Obsoletes: 1854 September 1997
+Category: Standards Track
+
+
+ SMTP Service Extension
+ for Command Pipelining
+
+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 a server
+ can indicate the extent of its ability to accept multiple commands in
+ a single TCP send operation. Using a single TCP send operation for
+ multiple commands can improve SMTP performance significantly.
+
+ The present document is an updated version of RFC 1854 [3]. Only
+ textual and editorial changes have been made; the protocol has not
+ changed in any way.
+
+2. Introduction
+
+ Although SMTP is widely and robustly deployed, certain extensions may
+ nevertheless prove useful. In particular, many parts of the Internet
+ make use of high latency network links. SMTP's intrinsic one
+ command-one response structure is significantly penalized by high
+ latency links, often to the point where the factors contributing to
+ overall connection time are dominated by the time spent waiting for
+ responses to individual commands (turnaround time).
+
+ In the best of all worlds it would be possible to simply deploy SMTP
+ client software that makes use of command pipelining: batching up
+ multiple commands into single TCP send operations. Unfortunately, the
+ original SMTP specification [1] did not explicitly state that SMTP
+ servers must support this. As a result a non-trivial number of
+ Internet SMTP servers cannot adequately handle command pipelining.
+ Flaws known to exist in deployed servers include:
+
+
+
+
+
+
+Freed Standards Track [Page 1]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ (1) Connection handoff and buffer flushes in the middle of
+ the SMTP dialogue. Creation of server processes for
+ incoming SMTP connections is a useful, obvious, and
+ harmless implementation technique. However, some SMTP
+ servers defer process forking and connection handoff
+ until some intermediate point in the SMTP dialogue.
+ When this is done material read from the TCP connection
+ and kept in process buffers can be lost.
+
+ (2) Flushing the TCP input buffer when an SMTP command
+ fails. SMTP commands often fail but there is no reason
+ to flush the TCP input buffer when this happens.
+ Nevertheless, some SMTP servers do this.
+
+ (3) Improper processing and promulgation of SMTP command
+ failures. For example, some SMTP servers will refuse to
+ accept a DATA command if the last RCPT TO command
+ fails, paying no attention to the success or failure of
+ prior RCPT TO command results. Other servers will
+ accept a DATA command even when all previous RCPT TO
+ commands have failed. Although it is possible to
+ accommodate this sort of behavior in a client that
+ employs command pipelining, it does complicate the
+ construction of the client unnecessarily.
+
+ This memo uses the mechanism described in [2] to define an extension
+ to the SMTP service whereby an SMTP server can declare that it is
+ capable of handling pipelined commands. The SMTP client can then
+ check for this declaration and use pipelining only when the server
+ declares itself capable of handling it.
+
+2.1. Requirements notation
+
+ This document occasionally uses terms that appear in capital letters.
+ When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
+ appear capitalized, they are being used to indicate particular
+ requirements of this specification. A discussion of the meanings of
+ these terms appears in RFC 2119 [4].
+
+3. Framework for the Command Pipelining Extension
+
+ The Command Pipelining extension is defined as follows:
+
+ (1) the name of the SMTP service extension is Pipelining;
+
+ (2) the EHLO keyword value associated with the extension is
+ PIPELINING;
+
+
+
+
+Freed Standards Track [Page 2]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ (3) no parameter is used with the PIPELINING EHLO keyword;
+
+ (4) no additional parameters are added to either the MAIL
+ FROM or RCPT TO commands.
+
+ (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.
+
+4. The Pipelining Service Extension
+
+ When a client SMTP wishes to employ command pipelining, 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 PIPELINING, then the server SMTP has indicated
+ that it can accommodate SMTP command pipelining.
+
+4.1. Client use of pipelining
+
+ Once the client SMTP has confirmed that support exists for the
+ pipelining extension, the client SMTP may then elect to transmit
+ groups of SMTP commands in batches without waiting for a response to
+ each individual command. In particular, the commands RSET, MAIL FROM,
+ SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere
+ in a pipelined command group. The EHLO, DATA, VRFY, EXPN, TURN,
+ QUIT, and NOOP commands can only appear as the last command in a
+ group since their success or failure produces a change of state which
+ the client SMTP must accommodate. (NOOP is included in this group so
+ it can be used as a synchronization point.)
+
+ Additional commands added by other SMTP extensions may only appear as
+ the last command in a group unless otherwise specified by the
+ extensions that define the commands.
+
+ The actual transfer of message content is explicitly allowed to be
+ the first "command" in a group. That is, a RSET/MAIL FROM sequence
+ used to initiate a new message transaction can be placed in the same
+ group as the final transfer of the headers and body of the previous
+ message.
+
+ Client SMTP implementations that employ pipelining MUST check ALL
+ statuses associated with each command in a group. For example, if
+ none of the RCPT TO recipient addresses were accepted the client must
+
+
+
+
+
+Freed Standards Track [Page 3]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ then check the response to the DATA command -- the client cannot
+ assume that the DATA command will be rejected just because none of
+ the RCPT TO commands worked. If the DATA command was properly
+ rejected the client SMTP can just issue RSET, but if the DATA command
+ was accepted the client SMTP should send a single dot.
+
+ Command statuses MUST be coordinated with responses by counting each
+ separate response and correlating that count with the number of
+ commands known to have been issued. Multiline responses MUST be
+ supported. Matching on the basis of either the error code value or
+ associated text is expressly forbidden.
+
+ Client SMTP implementations MAY elect to operate in a nonblocking
+ fashion, processing server responses immediately upon receipt, even
+ if there is still data pending transmission from the client's
+ previous TCP send operation. If nonblocking operation is not
+ supported, however, client SMTP implementations MUST also check the
+ TCP window size and make sure that each group of commands fits
+ entirely within the window. The window size is usually, but not
+ always, 4K octets. Failure to perform this check can lead to
+ deadlock conditions.
+
+ Clients MUST NOT confuse responses to multiple commands with
+ multiline responses. Each command requires one or more lines of
+ response, the last line not containing a dash between the response
+ code and the response string.
+
+4.2. Server support of pipelining
+
+ A server SMTP implementation that offers the pipelining extension:
+
+ (1) MUST NOT flush or otherwise lose the contents of the
+ TCP input buffer under any circumstances whatsoever.
+
+ (2) SHOULD issue a positive response to the DATA command if
+ and only if one or more valid RCPT TO addresses have
+ been previously received.
+
+ (3) MUST NOT, after issuing a positive response to a DATA
+ command with no valid recipients and subsequently
+ receiving an empty message, send any message whatsoever
+ to anybody.
+
+ (4) SHOULD elect to store responses to grouped RSET, MAIL
+ FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO
+ commands in an internal buffer so they can sent as a
+ unit.
+
+
+
+
+Freed Standards Track [Page 4]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ (5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN,
+ TURN, QUIT, and NOOP.
+
+ (6) MUST NOT buffer responses to unrecognized commands.
+
+ (7) MUST send all pending responses immediately whenever
+ the local TCP input buffer is emptied.
+
+ (8) MUST NOT make assumptions about commands that are yet
+ to be received.
+
+ (9) SHOULD issue response text that indicates, either
+ implicitly or explicitly, what command the response
+ matches.
+
+ The overriding intent of these server requirements is to make it as
+ easy as possible for servers to conform to these pipelining
+ extensions.
+
+5. Examples
+
+ Consider the following SMTP dialogue that does not use pipelining:
+
+ S: <wait for open connection>
+ C: <open connection to server>
+ S: 220 innosoft.com SMTP service ready
+ C: HELO dbc.mtview.ca.us
+ S: 250 innosoft.com
+ C: MAIL FROM:<mr...@dbc.mtview.ca.us>
+ S: 250 sender <mr...@dbc.mtview.ca.us> OK
+ C: RCPT TO:<ne...@innosoft.com>
+ S: 250 recipient <ne...@innosoft.com> OK
+ C: RCPT TO:<da...@innosoft.com>
+ S: 250 recipient <da...@innosoft.com> OK
+ C: RCPT TO:<kv...@innosoft.com>
+ S: 250 recipient <kv...@innosoft.com> OK
+ C: DATA
+ S: 354 enter mail, end with line containing only "."
+ ...
+ C: .
+ S: 250 message sent
+ C: QUIT
+ S: 221 goodbye
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 5]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ The client waits for a server response a total of 9 times in this
+ simple example. But if pipelining is employed the following dialogue
+ is possible:
+
+ S: <wait for open connection>
+ C: <open connection to server>
+ S: 220 innosoft.com SMTP service ready
+ C: EHLO dbc.mtview.ca.us
+ S: 250-innosoft.com
+ S: 250 PIPELINING
+ C: MAIL FROM:<mr...@dbc.mtview.ca.us>
+ C: RCPT TO:<ne...@innosoft.com>
+ C: RCPT TO:<da...@innosoft.com>
+ C: RCPT TO:<kv...@innosoft.com>
+ C: DATA
+ S: 250 sender <mr...@dbc.mtview.ca.us> OK
+ S: 250 recipient <ne...@innosoft.com> OK
+ S: 250 recipient <da...@innosoft.com> OK
+ S: 250 recipient <kv...@innosoft.com> OK
+ S: 354 enter mail, end with line containing only "."
+ ...
+ C: .
+ C: QUIT
+ S: 250 message sent
+ S: 221 goodbye
+
+
+ The total number of turnarounds has been reduced from 9 to 4.
+
+ The next example illustrates one possible form of behavior when
+ pipelining is used and all recipients are rejected:
+
+ S: <wait for open connection>
+ C: <open connection to server>
+ S: 220 innosoft.com SMTP service ready
+ C: EHLO dbc.mtview.ca.us
+ S: 250-innosoft.com
+ S: 250 PIPELINING
+ C: MAIL FROM:<mr...@dbc.mtview.ca.us>
+ C: RCPT TO:<ns...@thumper.bellcore.com>
+ C: RCPT TO:<ga...@tis.com>
+ C: DATA
+ S: 250 sender <mr...@dbc.mtview.ca.us> OK
+ S: 550 remote mail to <ns...@thumper.bellore.com> not allowed
+ S: 550 remote mail to <ga...@tis.com> not allowed
+ S: 554 no valid recipients given
+ C: QUIT
+ S: 221 goodbye
+
+
+
+Freed Standards Track [Page 6]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ The client SMTP waits for the server 4 times here as well. If the
+ server SMTP does not check for at least one valid recipient prior to
+ accepting the DATA command, the following dialogue would result:
+
+ S: <wait for open connection>
+ C: <open connection to server>
+ S: 220 innosoft.com SMTP service ready
+ C: EHLO dbc.mtview.ca.us
+ S: 250-innosoft.com
+ S: 250 PIPELINING
+ C: MAIL FROM:<mr...@dbc.mtview.ca.us>
+ C: RCPT TO:<ns...@thumper.bellcore.com>
+ C: RCPT TO:<ga...@tis.com>
+ C: DATA
+ S: 250 sender <mr...@dbc.mtview.ca.us> OK
+ S: 550 remote mail to <ns...@thumper.bellore.com> not allowed
+ S: 550 remote mail to <ga...@tis.com> not allowed
+ S: 354 enter mail, end with line containing only "."
+ C: .
+ C: QUIT
+ S: 554 no valid recipients
+ S: 221 goodbye
+
+6. Security Considerations
+
+ This document does not discuss security issues and is not believed to
+ raise any security issues not endemic in electronic mail and present
+ in fully conforming implementations of [1].
+
+7. Acknowledgements
+
+ This document is based on the SMTP service extension model presented
+ in RFC 1425. Marshall Rose's description of SMTP command pipelining
+ in his book "The Internet Message" also served as a source of
+ inspiration for this extension.
+
+8. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10,
+ RFC 821, August 1982.
+
+ [2] Klensin, J., Freed, N., Rose, M., Stefferud, E., and
+ D. Crocker, "SMTP Service Extensions", RFC 1869,
+ November 1995.
+
+ [3] Freed, N., "SMTP Service Extension for Command Pipelining",
+ RFC 1854, October 1995.
+
+
+
+
+Freed Standards Track [Page 7]
+
+RFC 2197 SMTP Service Extension September 1997
+
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+9. Author's Address
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 626 919 3600
+ Fax: +1 626 919 3614
+ EMail: ned.freed@innosoft.com
+
+ This document is a product of work done by the Internet Engineering
+ Task Force Working Group on Messaging Extensions, Alan Cargille,
+ chair.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed Standards Track [Page 8]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc2197.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc2554.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc2554.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc2554.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc2554.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,620 @@
+
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 2554 Netscape Communications
+Category: Standards Track March 1999
+
+
+ SMTP Service Extension
+ for Authentication
+
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+
+1. Introduction
+
+ This document defines an SMTP service extension [ESMTP] whereby an
+ SMTP client may indicate an authentication mechanism to the server,
+ perform an authentication protocol exchange, and optionally negotiate
+ a security layer for subsequent protocol interactions. This
+ extension is a profile of the Simple Authentication and Security
+ Layer [SASL].
+
+
+2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ in this document are to be interpreted as defined in "Key words for
+ use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+3. The Authentication service extension
+
+
+ (1) the name of the SMTP service extension is "Authentication"
+
+ (2) the EHLO keyword value associated with this extension is "AUTH"
+
+
+
+
+Myers Standards Track [Page 1]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ (3) The AUTH EHLO keyword contains as a parameter a space separated
+ list of the names of supported SASL mechanisms.
+
+ (4) a new SMTP verb "AUTH" is defined
+
+ (5) an optional parameter using the keyword "AUTH" is added to the
+ MAIL FROM command, and extends the maximum line length of the
+ MAIL FROM command by 500 characters.
+
+ (6) this extension is appropriate for the submission protocol
+ [SUBMIT].
+
+
+4. The AUTH command
+
+ AUTH mechanism [initial-response]
+
+ Arguments:
+ a string identifying a SASL authentication mechanism.
+ an optional base64-encoded response
+
+ Restrictions:
+ After an AUTH command has successfully completed, no more AUTH
+ commands may be issued in the same session. After a successful
+ AUTH command completes, a server MUST reject any further AUTH
+ commands with a 503 reply.
+
+ The AUTH command is not permitted during a mail transaction.
+
+ Discussion:
+ The AUTH command indicates an authentication mechanism to the
+ server. If the server supports the requested authentication
+ mechanism, it performs an authentication protocol exchange to
+ authenticate and identify the user. Optionally, it also
+ negotiates a security layer for subsequent protocol
+ interactions. If the requested authentication mechanism is not
+ supported, the server rejects the AUTH command with a 504
+ reply.
+
+ The authentication protocol exchange consists of a series of
+ server challenges and client answers that are specific to the
+ authentication mechanism. A server challenge, otherwise known
+ as a ready response, is a 334 reply with the text part
+ containing a BASE64 encoded string. The client answer consists
+ of a line containing a BASE64 encoded string. If the client
+ wishes to cancel an authentication exchange, it issues a line
+ with a single "*". If the server receives such an answer, it
+ MUST reject the AUTH command by sending a 501 reply.
+
+
+
+Myers Standards Track [Page 2]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ The optional initial-response argument to the AUTH command is
+ used to save a round trip when using authentication mechanisms
+ that are defined to send no data in the initial challenge.
+ When the initial-response argument is used with such a
+ mechanism, the initial empty challenge is not sent to the
+ client and the server uses the data in the initial-response
+ argument as if it were sent in response to the empty challenge.
+ Unlike a zero-length client answer to a 334 reply, a zero-
+ length initial response is sent as a single equals sign ("=").
+ If the client uses an initial-response argument to the AUTH
+ command with a mechanism that sends data in the initial
+ challenge, the server rejects the AUTH command with a 535
+ reply.
+
+ If the server cannot BASE64 decode the argument, it rejects the
+ AUTH command with a 501 reply. If the server rejects the
+ authentication data, it SHOULD reject the AUTH command with a
+ 535 reply unless a more specific error code, such as one listed
+ in section 6, is appropriate. Should the client successfully
+ complete the authentication exchange, the SMTP server issues a
+ 235 reply.
+
+ The service name specified by this protocol's profile of SASL
+ is "smtp".
+
+ If a security layer is negotiated through the SASL
+ authentication exchange, it takes effect immediately following
+ the CRLF that concludes the authentication exchange for the
+ client, and the CRLF of the success reply for the server. Upon
+ a security layer's taking effect, the SMTP protocol is reset to
+ the initial state (the state in SMTP after a server issues a
+ 220 service ready greeting). The server MUST discard any
+ knowledge obtained from the client, such as the argument to the
+ EHLO command, which was not obtained from the SASL negotiation
+ itself. The client MUST discard any knowledge obtained from
+ the server, such as the list of SMTP service extensions, which
+ was not obtained from the SASL negotiation itself (with the
+ exception that a client MAY compare the list of advertised SASL
+ mechanisms before and after authentication in order to detect
+ an active down-negotiation attack). The client SHOULD send an
+ EHLO command as the first command after a successful SASL
+ negotiation which results in the enabling of a security layer.
+
+ The server is not required to support any particular
+ authentication mechanism, nor are authentication mechanisms
+ required to support any security layers. If an AUTH command
+ fails, the client may try another authentication mechanism by
+ issuing another AUTH command.
+
+
+
+Myers Standards Track [Page 3]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ If an AUTH command fails, the server MUST behave the same as if
+ the client had not issued the AUTH command.
+
+ The BASE64 string may in general be arbitrarily long. Clients
+ and servers MUST be able to support challenges and responses
+ that are as long as are generated by the authentication
+ mechanisms they support, independent of any line length
+ limitations the client or server may have in other parts of its
+ protocol implementation.
+
+ Examples:
+ S: 220 smtp.example.com ESMTP server ready
+ C: EHLO jgm.example.com
+ S: 250-smtp.example.com
+ S: 250 AUTH CRAM-MD5 DIGEST-MD5
+ C: AUTH FOOBAR
+ S: 504 Unrecognized authentication type.
+ C: AUTH CRAM-MD5
+ S: 334
+ PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
+ C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
+ S: 235 Authentication successful.
+
+
+
+5. The AUTH parameter to the MAIL FROM command
+
+ AUTH=addr-spec
+
+ Arguments:
+ An addr-spec containing the identity which submitted the message
+ to the delivery system, or the two character sequence "<>"
+ indicating such an identity is unknown or insufficiently
+ authenticated. To comply with the restrictions imposed on ESMTP
+ parameters, the addr-spec is encoded inside an xtext. The syntax
+ of an xtext is described in section 5 of [ESMTP-DSN].
+
+ Discussion:
+ The optional AUTH parameter to the MAIL FROM command allows
+ cooperating agents in a trusted environment to communicate the
+ authentication of individual messages.
+
+ If the server trusts the authenticated identity of the client to
+ assert that the message was originally submitted by the supplied
+ addr-spec, then the server SHOULD supply the same addr-spec in an
+ AUTH parameter when relaying the message to any server which
+ supports the AUTH extension.
+
+
+
+
+Myers Standards Track [Page 4]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ A MAIL FROM parameter of AUTH=<> indicates that the original
+ submitter of the message is not known. The server MUST NOT treat
+ the message as having been originally submitted by the client.
+
+ If the AUTH parameter to the MAIL FROM is not supplied, the
+ client has authenticated, and the server believes the message is
+ an original submission by the client, the server MAY supply the
+ client's identity in the addr-spec in an AUTH parameter when
+ relaying the message to any server which supports the AUTH
+ extension.
+
+ If the server does not sufficiently trust the authenticated
+ identity of the client, or if the client is not authenticated,
+ then the server MUST behave as if the AUTH=<> parameter was
+ supplied. The server MAY, however, write the value of the AUTH
+ parameter to a log file.
+
+ If an AUTH=<> parameter was supplied, either explicitly or due to
+ the requirement in the previous paragraph, then the server MUST
+ supply the AUTH=<> parameter when relaying the message to any
+ server which it has authenticated to using the AUTH extension.
+
+ A server MAY treat expansion of a mailing list as a new
+ submission, setting the AUTH parameter to the mailing list
+ address or mailing list administration address when relaying the
+ message to list subscribers.
+
+ It is conforming for an implementation to be hard-coded to treat
+ all clients as being insufficiently trusted. In that case, the
+ implementation does nothing more than parse and discard
+ syntactically valid AUTH parameters to the MAIL FROM command and
+ supply AUTH=<> parameters to any servers to which it
+ authenticates using the AUTH extension.
+
+ Examples:
+ C: MAIL FROM:<e=...@example.com> AUTH=e+3Dmc2@example.com
+ S: 250 OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 5]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+6. Error Codes
+
+ The following error codes may be used to indicate various conditions
+ as described.
+
+ 432 A password transition is needed
+
+ This response to the AUTH command indicates that the user needs to
+ transition to the selected authentication mechanism. This typically
+ done by authenticating once using the PLAIN authentication mechanism.
+
+ 534 Authentication mechanism is too weak
+
+ This response to the AUTH command indicates that the selected
+ authentication mechanism is weaker than server policy permits for
+ that user.
+
+ 538 Encryption required for requested authentication mechanism
+
+ This response to the AUTH command indicates that the selected
+ authentication mechanism may only be used when the underlying SMTP
+ connection is encrypted.
+
+ 454 Temporary authentication failure
+
+ This response to the AUTH command indicates that the authentication
+ failed due to a temporary server failure.
+
+ 530 Authentication required
+
+ This response may be returned by any command other than AUTH, EHLO,
+ HELO, NOOP, RSET, or QUIT. It indicates that server policy requires
+ authentication in order to perform the requested action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 6]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+7. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in [ABNF].
+
+ Except as noted otherwise, all alphabetic characters are case-
+ insensitive. The use of upper or lower case characters to define
+ token strings is for editorial clarity only. Implementations MUST
+ accept these strings in a case-insensitive fashion.
+
+ UPALPHA = %x41-5A ;; Uppercase: A-Z
+
+ LOALPHA = %x61-7A ;; Lowercase: a-z
+
+ ALPHA = UPALPHA / LOALPHA ;; case insensitive
+
+ DIGIT = %x30-39 ;; Digits 0-9
+
+ HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
+
+ hexchar = "+" HEXDIGIT HEXDIGIT
+
+ xchar = %x21-2A / %x2C-3C / %x3E-7E
+ ;; US-ASCII except for "+", "=", SPACE and CTL
+
+ xtext = *(xchar / hexchar)
+
+ AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
+
+ auth_type = 1*20AUTH_CHAR
+
+ auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
+ *(CRLF [base64]) CRLF
+
+ auth_param = "AUTH=" xtext
+ ;; The decoded form of the xtext MUST be either
+ ;; an addr-spec or the two characters "<>"
+
+ base64 = base64_terminal /
+ ( 1*(4base64_CHAR) [base64_terminal] )
+
+ base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
+ ;; Case-sensitive
+
+ base64_terminal = (2base64_char "==") / (3base64_char "=")
+
+ continue_req = "334" SPACE [base64] CRLF
+
+
+
+
+Myers Standards Track [Page 7]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ CR = %x0C ;; ASCII CR, carriage return
+
+ CRLF = CR LF
+
+ CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
+
+ LF = %x0A ;; ASCII LF, line feed
+
+ SPACE = %x20 ;; ASCII SP, space
+
+
+
+
+8. References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+ AUTHorize Extension for Simple Challenge/Response", RFC
+ 2195, September 1997.
+
+ [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+ Crocker, "SMTP Service Extensions", RFC 1869, November
+ 1995.
+
+ [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
+ Notifications", RFC 1891, January 1996.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC
+ 2476, December 1998.
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 8]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+9. Security Considerations
+
+ Security issues are discussed throughout this memo.
+
+ If a client uses this extension to get an encrypted tunnel through an
+ insecure network to a cooperating server, it needs to be configured
+ to never send mail to that server when the connection is not mutually
+ authenticated and encrypted. Otherwise, an attacker could steal the
+ client's mail by hijacking the SMTP connection and either pretending
+ the server does not support the Authentication extension or causing
+ all AUTH commands to fail.
+
+ Before the SASL negotiation has begun, any protocol interactions are
+ performed in the clear and may be modified by an active attacker.
+ For this reason, clients and servers MUST discard any knowledge
+ obtained prior to the start of the SASL negotiation upon completion
+ of a SASL negotiation which results in a security layer.
+
+ This mechanism does not protect the TCP port, so an active attacker
+ may redirect a relay connection attempt to the submission port
+ [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing
+ an relayed message without an envelope authentication to pick up the
+ authentication of the relay client.
+
+ A message submission client may require the user to authenticate
+ whenever a suitable SASL mechanism is advertised. Therefore, it may
+ not be desirable for a submission server [SUBMIT] to advertise a SASL
+ mechanism when use of that mechanism grants the client no benefits
+ over anonymous submission.
+
+ This extension is not intended to replace or be used instead of end-
+ to-end message signature and encryption systems such as S/MIME or
+ PGP. This extension addresses a different problem than end-to-end
+ systems; it has the following key differences:
+
+ (1) it is generally useful only within a trusted enclave
+
+ (2) it protects the entire envelope of a message, not just the
+ message's body.
+
+ (3) it authenticates the message submission, not authorship of the
+ message content
+
+ (4) it can give the sender some assurance the message was
+ delivered to the next hop in the case where the sender
+ mutually authenticates with the next hop and negotiates an
+ appropriate security layer.
+
+
+
+
+Myers Standards Track [Page 9]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+ Additional security considerations are mentioned in the SASL
+ specification [SASL].
+
+
+
+10. Author's Address
+
+ John Gardiner Myers
+ Netscape Communications
+ 501 East Middlefield Road
+ Mail Stop MV-029
+ Mountain View, CA 94043
+
+ EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 10]
+
+RFC 2554 SMTP Authentication March 1999
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 11]
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc2554.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