As per Relevance of the word response, we have this rfc below:
Network Working Group J. Klensin, WG
Request for Comments: 1425 United Nations
N. Freed,
Innosoft International, Inc
M.
Dover Beach Consulting, Inc
E.
Network Management Associates, Inc
D.
The Branch
February 1993
SMTP Service
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
1.
This memo defines 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. Standard extensions to the
service are registered with the Internet Assigned Numbers
(IANA). This framework does not require modification of
SMTP clients or servers unless the features of the service
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, Freed, Rose, Stefferud & Crocker [Page 1]
RFC 1425 SMTP Service Extensions February 1993
(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. The
form a collection of field/value pairs
according to RFC 822 [2], whilst the body, if structured
is defined according to MIME [3]. The content is
in nature, expressed using the US ASCII repertoire (
X3.4-1986). Although extensions (such as MIME) may
this restriction for the content body, the
headers are always encoded using the US ASCII repertoire
The algorithm defined in [4] is used to represent
values outside the US ASCII repertoire, whilst
encoding them using the 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, Freed, Rose, Stefferud & Crocker [Page 2]
RFC 1425 SMTP Service Extensions February 1993
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.1), a failure response (see 4.2),
or an error response (4.3). If the SMTP server does not support
SMTP service extensions it will generate an error response (
section 4.4).
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.
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.1. 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
Klensin, Freed, Rose, Stefferud & Crocker [Page 3]
RFC 1425 SMTP Service Extensions February 1993
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)>
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 standard SMTP service extensions
Associated with each such extension is a corresponding EHLO
value. Each service extension registered with the IANA is defined
a standards-track RFC, and such a definition includes
(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
Klensin, Freed, Rose, Stefferud & Crocker [Page 4]
RFC 1425 SMTP Service Extensions February 1993
(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 the
FROM or RCPT TO verbs; and
(6) how support for the extension affects the behavior of
server and client SMTP
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 an SMTP service extension registered
IANA. A conforming server must not offer non "X" prefixed
values that are not described in a registered extension
Additional verbs are bound by the same rules as EHLO keywords
specifically, verbs begining with "X" are local extensions that
not be standardized and verbs not beginning with "X" must always
registered
4.2. 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.3. 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
Klensin, Freed, Rose, Stefferud & Crocker [Page 5]
RFC 1425 SMTP Service Extensions February 1993
4.4. 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.
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*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
Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
RFC 1425 SMTP Service Extensions February 1993
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 those
commands which are defined as mandatory in [5].
(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-
Klensin, Freed, Rose, Stefferud & Crocker [Page 7]
RFC 1425 SMTP Service Extensions February 1993
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 non-standard service extensions (
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 does
implement the extensions specified here. The
would normally send RSET to reset the connection, and
after getting a successful reply, send a HELO command
proceed as specified in RFC 821.
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
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
Klensin, Freed, Rose, Stefferud & Crocker [Page 8]
RFC 1425 SMTP Service Extensions February 1993
Miller, Dan Oscarsson, Julian Onions, Rayan Zachariassen, and
contributions of the entire IETF SMTP Working Group. Of course,
of the individuals are necessarily responsible for the combination
ideas represented here. Indeed, in some cases, the response to
particular criticism was to accept the problem identification but
include an entirely different solution from the one
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 1341, Bellcore, Innosoft, June 1992.
[4] Moore, K., "Representation of Non-ASCII Text in Internet
Headers", RFC 1342, University of Tennessee, June 1992.
[5] Braden, R., "Requirements for Internet Hosts - Application
Support", STD 3, RFC 1123, USC/Information Sciences Institute
October 1989.
12. Chair, Editor, and Authors'
John Klensin, WG
United Nations
PO Box 500, Charles Street
Boston, MA 02114-0500
Phone: +1 617 227 8747
Fax: +1 617 491 6266
Email: klensin@infoods.unu.
Ned Freed,
Innosoft International, Inc
250 West First Street, Suite 240
Claremont, CA 91711
Phone: +1 909 624 7907
Fax: +1 909 621 5319
Email: ned@innosoft.
Klensin, Freed, Rose, Stefferud & Crocker [Page 9]
RFC 1425 SMTP Service Extensions February 1993
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.
David H.
The Branch
Email: dcrocker@mordor.stanford.
Klensin, Freed, Rose, Stefferud & Crocker [Page 10]
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
