As per Relevance of the word response, we have this rfc below:
Network Working Group J. Klensin, WG
Request For Comments: 1869
STD: 10 N. Freed,
Obsoletes: 1651 Innosoft International, Inc
Category: Standards Track M.
Dover Beach Consulting, Inc
E.
Network Management Associates, Inc
D.
Brandenburg
November 1995
SMTP Service
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
This memo defines a framework for extending the SMTP service
defining a means whereby a server SMTP can inform a client SMTP as
the service extensions it supports. Extensions to the SMTP
are registered with the IANA. This framework does not
modification of existing SMTP clients or servers unless the
of the service extensions are to be requested or provided
2.
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
evident. Rather than describing these extensions as separate
haphazard entities, this document enhances SMTP in a
fashion that provides a framework in which all future extensions
be built in a single consistent way
3. Framework for SMTP
For the purpose of service extensions to SMTP, SMTP relays a
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
series of SMTP protocol units: it consists of
originator address (to which error reports should
directed); a delivery mode (e.g., deliver to
mailboxes); and, one or more recipient addresses
(2) The SMTP content is sent in the SMTP DATA protocol
and has two parts: the headers and the body.
headers form a collection of field/value
structured according to RFC 822 [2], whilst the body
if structured, is defined according to MIME [3].
content is textual in nature, expressed using the
ASCII repertoire (ANSI X3.4-1986). Although
(such as MIME) may relax this restriction for
content body, the content headers are always
using the US ASCII repertoire. The algorithm defined
[4] is used to represent header values outside the
ASCII repertoire, whilst still encoding them using
US ASCII repertoire
Although SMTP is widely and robustly deployed, some parts of
Internet community might wish to extend the SMTP service. This
defines a means whereby both an extended SMTP client and server
recognize each other as such and the server can inform the client
to the service extensions that it supports
It must be emphasized that any extension to the SMTP service
not be considered lightly. SMTP's strength comes primarily from
simplicity. Experience with many protocols has shown that
protocols with few options tend towards ubiquity,
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
extending the SMTP service will likely outweigh the benefit
Given this environment, the framework for the extensions described
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
commands (section 6).
Klensin, et al Standards Track [Page 2]
RFC 1869 SMTP Service Extensions November 1995
4. The EHLO
A client SMTP supporting SMTP service extensions should start an
session by issuing the EHLO command instead of the HELO command.
the SMTP server supports the SMTP service extensions it will give
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
SMTP service extensions it will generate an error response (
section 4.5).
4.1. Changes to STD 10, RFC 821
This specification is intended to extend STD 10, RFC 821
impacting existing services in any way. The minor changes needed
enumerated below
4.1.1. First
RFC 821 states that the first command in an SMTP session must be
HELO command. This requirement is hereby amended to allow a
to start with either EHLO or HELO
4.1.2. Maximum command line
This specification extends the SMTP MAIL FROM and RCPT TO to
additional parameters and parameter values. It is possible that
MAIL FROM and RCPT TO lines that result will exceed the 512
limit on command line length imposed by RFC 821. This limit
hereby amended to only apply to command lines without any parameters
Each specification that defines new MAIL FROM or RCPT TO
must also specify maximum parameter value lengths for each
so that implementors of some set of extensions know how much
space must be allocated. The maximum command length that must
supported by an SMTP implementation with extensions is 512 plus
sum of all the maximum parameter lengths for all the
supported
4.2. Command
The syntax for this command, using the ABNF notation of [2], is
ehlo-cmd ::= "EHLO" SP domain CR
If successful, the server SMTP responds with code 250. On failure
the server SMTP responds with code 550. On error, the server
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
at any time that a HELO command would be appropriate. That is,
the EHLO command is issued, and a successful response is returned
then a subsequent HELO or EHLO command will result in the server
replying with code 503. A client SMTP must not cache any
returned if the EHLO command succeeds. That is, a client SMTP
issue the EHLO command at the start of each SMTP session
information about extended facilities is needed
4.3. Successful
If the server SMTP implements and is able to perform the
command, it will return code 250. This indicates that both
server and client SMTP are in the initial state, that is, there is
transaction in progress and all state tables and buffers are cleared
Normally, this response will be a multiline reply. Each line of
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
/ ( "250-" domain [ SP greeting ] CR
*( "250-" ehlo-line CR LF )
"250" SP ehlo-line CR LF )
; the usual HELO chit-
greeting ::= 1*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-
ehlo-param ::= 1*
control characters (US ASCII 0-31
inclusive)>
ALPHA ::=
(A through Z in upper case, and
a through z in lower case)>
DIGIT ::=
(0 through 9)>
CR ::=
(ASCII decimal code 13)>
LF ::=
(ASCII decimal code 10)>
Klensin, et al Standards Track [Page 4]
RFC 1869 SMTP Service Extensions November 1995
SP ::=
(ASCII decimal code 32)>
Although EHLO keywords may be specified in upper, lower, or
case, they must always be recognized and processed in a case
insensitive manner. This is simply an extension of practices begun
RFC 821.
The IANA maintains a registry of SMTP service extensions.
with each such extension is a corresponding EHLO keyword value.
service extension registered with the IANA must be defined in an RFC
Such RFCs must either be on the standards-track or must define
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
with the EHLO keyword value
(4) any additional SMTP verbs associated with the
(additional verbs will usually be, but are not
to be, the same as the EHLO keyword value);
(5) any new parameters the extension associates with
MAIL FROM or RCPT TO verbs
(6) how support for the extension affects the behavior of
server and client SMTP; and
(7) the increment by which the extension is increasing
maximum length of the commands MAIL FROM, RCPT TO,
both, over that specified in RFC 821.
In addition, any EHLO keyword value that starts with an upper
lower case "X" refers to a local SMTP service extension, which
used through bilateral, rather than standardized, agreement.
beginning with "X" may not be used in a registered service extension
Any keyword values presented in the EHLO response that do not
with "X" must correspond to a standard, standards-track, or IESG
approved experimental SMTP service extension registered with IANA.
conforming server must not offer non "X" prefixed keyword values
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
not be registered or standardized and verbs not beginning with "X
must always be registered
4.4. Failure
If for some reason the server SMTP is unable to list the
extensions it supports, it will return code 554.
In the case of a failure response, the client SMTP should
either the HELO or QUIT command
4.5. Error responses from extended
If the server SMTP recognizes the EHLO command, but the
argument is unacceptable, it will return code 501.
If the server SMTP recognizes, but does not implement, the
command, it will return code 502.
If the server SMTP determines that the SMTP service is no
available (e.g., due to imminent system shutdown), it will
code 421.
In the case of any error response, the client SMTP should
either the HELO or QUIT command
4.6. Responses from servers without
A server SMTP that conforms to RFC 821 but does not support
extensions specified here will not recognize the EHLO command
will consequently return code 500, as specified in RFC 821.
server SMTP should stay in the same state after returning this
(see section 4.1.1 of RFC 821). The client SMTP may then
either a HELO or a QUIT command
4.7. Responses from improperly implemented
Some SMTP servers are known to disconnect the SMTP
channel upon receipt of the EHLO command. The disconnect can
immediately or after sending a response. Such behavior
section 4.1.1 of RFC 821, which explicitly states that
should only occur after a QUIT command is issued
Nevertheless, in order to achieve maxmimum interoperablity it
suggested that extended SMTP clients using EHLO be coded to check
server connection closure after EHLO is sent, either before or
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
operation can be successfully completed without using any
extensions. If it can a new connection can be opened and the
command can be used
Other improperly-implemented servers will not accept a HELO
after EHLO has been sent and rejected. In some cases, this
can be worked around by sending a RSET after the failure response
EHLO, then sending the HELO. Clients that do this should be
that many implementations will return a failure code (e.g., 503
sequence of commands) in response to the RSET. This code can
safely ignored
5. Initial IANA
The IANA's initial registry of SMTP service extensions consists
these entries
Service Ext EHLO Keyword Parameters Verb Added
------------- ------------ ---------- ---------- ------------------
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
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
It is recognized that several of the extensions planned for SMTP
make use of additional parameters associated with the MAIL FROM
RCPT TO command. The syntax for these commands, again using the
notation of [2] as well as underlying definitions from [1], is
esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR
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-
esmtp-value ::= 1*Standards Track [Page 7]
RFC 1869 SMTP Service Extensions November 1995
; The following commands are extended
; 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
registration process described above. This definition only
the framework for future extension; no extended MAIL FROM or RCPT
parameters are defined by this RFC
6.1. Error
If the server SMTP does not recognize or cannot implement one or
of the parameters associated with a particular MAIL FROM or RCPT
command, it will return code 555.
If for some reason the server is temporarily unable to accomodate
or more of the parameters associated with a MAIL FROM or RCPT
command, and if the definition of the specific parameter does
mandate the use of another code, it should return code 455.
Errors specific to particular parameters and their values will
specified in the parameter's defining RFC
7. Received: Header Field
SMTP servers are required to add an appropriate Received: field
the headers of all messages they receive. A "with ESMTP"
should be added to this field when any SMTP service extensions
used. "ESMTP" is hereby added to the list of standard protocol
registered with IANA
8. Usage
(1) An interaction of the form
S: connection on TCP port 25>
C: connection to server
S: 220 dbc.mtview.ca.us SMTP service
C: EHLO ymir.claremont.
S: 250 dbc.mtview.ca.us says
...
indicates that the server SMTP implements only
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: connection on TCP port 25>
C: connection to server
S: 220 dbc.mtview.ca.us SMTP service
C: EHLO ymir.claremont.
S: 250-dbc.mtview.ca.us says
S: 250-
S: 250-
S: 250-8
S: 250-
S: 250
...
indicates that the server SMTP also implements the
EXPN and HELP commands, one standard service
(8BITMIME), and two nonstandard and
service extensions (XONE and XVRB).
(3) Finally, a server that does not support SMTP
extensions would act as follows
S: connection on TCP port 25>
C: connection to server
S: 220 dbc.mtview.ca.us SMTP service
C: EHLO ymir.claremont.
S: 500 Command not recognized:
...
The 500 response indicates that the server SMTP
not implement the extensions specified here.
client would normally send a HELO command and
as specified in RFC 821. See section 4.7
additional discussion
9. Security
This RFC does not discuss security issues and is not believed
raise any security issues not already endemic in electronic mail
present in fully conforming implementations of RFC-821. It
provide an announcement of server mail capabilities via the
to the EHLO verb. However, all information provided by
of any of the initial set of service extensions defined by this
can be readily deduced by selective probing of the verbs required
transport and deliver mail. The security implications of
extensions described in other RFCs should be dealt with in
RFCs
Klensin, et al Standards Track [Page 9]
RFC 1869 SMTP Service Extensions November 1995
10.
This document represents a synthesis of the ideas of many people
reactions to the ideas and proposals of others. Randall Atkinson
Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed
and text sufficient to be considered co-authors. Other
suggestions, text, or encouragement came from Harald Alvestrand,
Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson,
Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A
Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions,
Zachariassen, and the contributions of the entire IETF SMTP
Group. Of course, none of the individuals are necessarily
for the combination of ideas represented here. Indeed, in some cases
the response to a particular criticism was to accept the
identification but to include an entirely different solution from
one originally proposed
11.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Borenstein, N., and N. Freed, "Multipurpose Internet
Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
[4] Moore, K., "Representation of Non-ASCII Text in Internet
Headers", RFC 1522, University of Tennessee, September 1993.
[5] Braden, R., "Requirements for Internet Hosts - Application
Support", STD 3, RFC 1123, USC/Information Sciences Institute
October 1989.
12. Chair, Editor, and Author
John Klensin, WG
2100 Reston
Reston, VA 22091
Phone: +1 703 715-7361
Fax: +1 703 715-7436
EMail: klensin@mci.
Klensin, et al Standards Track [Page 10]
RFC 1869 SMTP Service Extensions November 1995
Ned Freed,
Innosoft International, Inc
1050 East Garvey Avenue
West Covina, CA 91790
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.
Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Moutain View, CA 94043-2186
Phone: +1 415 968 1052
Fax: +1 415 968 2510
EMail: mrose@dbc.mtview.ca.
Einar A.
Network Management Associates, Inc
17301 Drey
Huntington Beach, CA, 92647-5615
Phone: +1 714 842 3711
Fax: +1 714 848 2091
EMail: stef@nma.
Dave
Brandenburg
675 Spruce Dr
Sunnyvale, CA 94086
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@mordor.stanford.
Klensin, et al Standards Track [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
