draft-ietf-smtpext-extensions-04.txt   rfc1869.txt 
Network Working Group John Klensin, WG Chair Network Working Group J. Klensin, WG Chair
Internet Draft Ned Freed, Editor Request For Comments: 1869 MCI
<draft-ietf-smtpext-extensions-04.txt> Marshall Rose STD: 10 N. Freed, Editor
Einar Stefferud Obsoletes: 1651 Innosoft International, Inc.
David Crocker Category: Standards Track M. Rose
Dover Beach Consulting, Inc.
SMTP Service Extensions E. Stefferud
Network Management Associates, Inc.
May 6, 1995 D. Crocker
Brandenburg Consulting
Status of this Memo November 1995
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six SMTP Service Extensions
months. Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet-Drafts as reference material or to cite them other
than as a "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please Status of this Memo
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
or munnari.oz.au (Pacific Rim).
This draft is intended to supercede RFC 1651. 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 1. Abstract
This memo defines a framework for extending the SMTP service This memo defines a framework for extending the SMTP service by
by defining a means whereby a server SMTP can inform a client defining a means whereby a server SMTP can inform a client SMTP as to
SMTP as to the service extensions it supports. Extensions to the service extensions it supports. Extensions to the SMTP service
the SMTP service are registered with the IANA. This framework are registered with the IANA. This framework does not require
does not require modification of existing SMTP clients or modification of existing SMTP clients or servers unless the features
servers unless the features of the service extensions are to of the service extensions are to be requested or provided.
be requested or provided.
2. Introduction 2. Introduction
The Simple Mail Transfer Protocol (SMTP) [1] has provided a The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable,
stable, effective basis for the relay function of message effective basis for the relay function of message transfer agents.
transfer agents. Although a decade old, SMTP has proven Although a decade old, SMTP has proven remarkably resilient.
remarkably resilient. Nevertheless, the need for a number of Nevertheless, the need for a number of protocol extensions has become
protocol extensions has become evident. Rather than describing evident. Rather than describing these extensions as separate and
these extensions as separate and haphazard entities, this haphazard entities, this document enhances SMTP in a straightforward
document enhances SMTP in a straightforward fashion that fashion that provides a framework in which all future extensions can
provides a framework in which all future extensions can be be built in a single consistent way.
built in a single consistent way.
3. Framework for SMTP Extensions 3. Framework for SMTP Extensions
For the purpose of service extensions to SMTP, SMTP relays a For the purpose of service extensions to SMTP, SMTP relays a mail
mail object containing an envelope and a content. object containing an envelope and a content.
(1) The SMTP envelope is straightforward, and is sent as a (1) The SMTP envelope is straightforward, and is sent as a
series of SMTP protocol units: it consists of an series of SMTP protocol units: it consists of an
originator address (to which error reports should be originator address (to which error reports should be
directed); a delivery mode (e.g., deliver to recipient directed); a delivery mode (e.g., deliver to recipient
mailboxes); and, one or more recipient addresses. mailboxes); and, one or more recipient addresses.
(2) The SMTP content is sent in the SMTP DATA protocol unit (2) The SMTP content is sent in the SMTP DATA protocol unit
and has two parts: the headers and the body. The and has two parts: the headers and the body. The
headers form a collection of field/value pairs headers form a collection of field/value pairs
skipping to change at page 2, line ? skipping to change at page 2, line 25
if structured, is defined according to MIME [3]. The if structured, is defined according to MIME [3]. The
content is textual in nature, expressed using the US content is textual in nature, expressed using the US
ASCII repertoire (ANSI X3.4-1986). Although extensions ASCII repertoire (ANSI X3.4-1986). Although extensions
(such as MIME) may relax this restriction for the (such as MIME) may relax this restriction for the
content body, the content headers are always encoded content body, the content headers are always encoded
using the US ASCII repertoire. The algorithm defined in using the US ASCII repertoire. The algorithm defined in
[4] is used to represent header values outside the US [4] is used to represent header values outside the US
ASCII repertoire, whilst still encoding them using the ASCII repertoire, whilst still encoding them using the
US ASCII repertoire. US ASCII repertoire.
Although SMTP is widely and robustly deployed, some parts of Although SMTP is widely and robustly deployed, some parts of the
the Internet community might wish to extend the SMTP service. Internet community might wish to extend the SMTP service. This memo
This memo defines a means whereby both an extended SMTP client defines a means whereby both an extended SMTP client and server may
and server may recognize each other as such and the server can recognize each other as such and the server can inform the client as
inform the client as to the service extensions that it to the service extensions that it supports.
supports.
It must be emphasized that any extension to the SMTP service It must be emphasized that any extension to the SMTP service should
should not be considered lightly. SMTP's strength comes not be considered lightly. SMTP's strength comes primarily from its
primarily from its simplicity. Experience with many protocols simplicity. Experience with many protocols has shown that:
has shown that:
protocols with few options tend towards ubiquity, whilst protocols with few options tend towards ubiquity, whilst
protocols with many options tend towards obscurity. protocols with many options tend towards obscurity.
This means that each and every extension, regardless of its This means that each and every extension, regardless of its benefits,
benefits, must be carefully scrutinized with respect to its must be carefully scrutinized with respect to its implementation,
implementation, deployment, and interoperability costs. In deployment, and interoperability costs. In many cases, the cost of
many cases, the cost of extending the SMTP service will likely extending the SMTP service will likely outweigh the benefit.
outweigh the benefit.
Given this environment, the framework for the extensions Given this environment, the framework for the extensions described in
described in this memo consists of: this memo consists of:
(1) a new SMTP command (section 4) (1) a new SMTP command (section 4)
(2) a registry of SMTP service extensions (section 5) (2) a registry of SMTP service extensions (section 5)
(3) additional parameters to the SMTP MAIL FROM and RCPT TO (3) additional parameters to the SMTP MAIL FROM and RCPT TO
commands (section 6). commands (section 6).
4. The EHLO command 4. The EHLO command
A client SMTP supporting SMTP service extensions should start A client SMTP supporting SMTP service extensions should start an SMTP
an SMTP session by issuing the EHLO command instead of the session by issuing the EHLO command instead of the HELO command. If
HELO command. If the SMTP server supports the SMTP service the SMTP server supports the SMTP service extensions it will give a
extensions it will give a successful response (see section successful response (see section 4.3), a failure response (see 4.4),
4.3), a failure response (see 4.4), or an error response or an error response (4.5). If the SMTP server does not support any
(4.5). If the SMTP server does not support any SMTP service SMTP service extensions it will generate an error response (see
extensions it will generate an error response (see section section 4.5).
4.5).
4.1. Changes to RFC 821 4.1. Changes to STD 10, RFC 821
This specification is intended to extend RFC 821 without This specification is intended to extend STD 10, RFC 821 without
impacting existing services in any way. The minor changes impacting existing services in any way. The minor changes needed are
needed are enumerated below. enumerated below.
4.1.1. First command 4.1.1. First command
RFC 821 states that the first command in an SMTP session must RFC 821 states that the first command in an SMTP session must be the
be the HELO command. This requirement is hereby amended to HELO command. This requirement is hereby amended to allow a session
allow a session to start with either EHLO or HELO. to start with either EHLO or HELO.
4.1.2. Maximum command line length 4.1.2. Maximum command line length
This specification extends the SMTP MAIL FROM and RCPT TO to This specification extends the SMTP MAIL FROM and RCPT TO to allow
allow additional parameters and parameter values. It is additional parameters and parameter values. It is possible that the
possible that the MAIL FROM and RCPT TO lines that result will MAIL FROM and RCPT TO lines that result will exceed the 512 character
exceed the 512 character limit on command line length imposed limit on command line length imposed by RFC 821. This limit is
by RFC 821. This limit is hereby amended to only apply to hereby amended to only apply to command lines without any parameters.
command lines without any parameters. Each specification that Each specification that defines new MAIL FROM or RCPT TO parameters
defines new MAIL FROM or RCPT TO parameters must also specify must also specify maximum parameter value lengths for each parameter
maximum parameter value lengths for each parameter so that so that implementors of some set of extensions know how much buffer
implementors of some set of extensions know how much buffer space must be allocated. The maximum command length that must be
space must be allocated. The maximum command length that must supported by an SMTP implementation with extensions is 512 plus the
be supported by an SMTP implementation with extensions is 512 sum of all the maximum parameter lengths for all the extensions
plus the sum of all the maximum parameter lengths for all the supported.
extensions supported.
4.2. Command syntax 4.2. Command syntax
The syntax for this command, using the ABNF notation of [2], The syntax for this command, using the ABNF notation of [2], is:
is:
ehlo-cmd ::= "EHLO" SP domain CR LF ehlo-cmd ::= "EHLO" SP domain CR LF
If successful, the server SMTP responds with code 250. On If successful, the server SMTP responds with code 250. On failure,
failure, the server SMTP responds with code 550. On error, the the server SMTP responds with code 550. On error, the server SMTP
server SMTP responds with one of codes 500, 501, 502, 504, or responds with one of codes 500, 501, 502, 504, or 421.
421.
This command is issued instead of the HELO command, and may be This command is issued instead of the HELO command, and may be issued
issued at any time that a HELO command would be appropriate. at any time that a HELO command would be appropriate. That is, if
That is, if the EHLO command is issued, and a successful the EHLO command is issued, and a successful response is returned,
response is returned, then a subsequent HELO or EHLO command then a subsequent HELO or EHLO command will result in the server SMTP
will result in the server SMTP replying with code 503. A replying with code 503. A client SMTP must not cache any information
client SMTP must not cache any information returned if the returned if the EHLO command succeeds. That is, a client SMTP must
EHLO command succeeds. That is, a client SMTP must issue the issue the EHLO command at the start of each SMTP session if
EHLO command at the start of each SMTP session if information information about extended facilities is needed.
about extended facilities is needed.
4.3. Successful response 4.3. Successful response
If the server SMTP implements and is able to perform the EHLO If the server SMTP implements and is able to perform the EHLO
command, it will return code 250. This indicates that both command, it will return code 250. This indicates that both the
the server and client SMTP are in the initial state, that is, server and client SMTP are in the initial state, that is, there is no
there is no transaction in progress and all state tables and transaction in progress and all state tables and buffers are cleared.
buffers are cleared.
Normally, this response will be a multiline reply. Each line Normally, this response will be a multiline reply. Each line of the
of the response contains a keyword and, optionally, one or response contains a keyword and, optionally, one or more parameters.
more parameters. The syntax for a positive response, using the The syntax for a positive response, using the ABNF notation of [2],
ABNF notation of [2], is: is:
ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
/ ( "250-" domain [ SP greeting ] CR LF / ( "250-" domain [ SP greeting ] CR LF
*( "250-" ehlo-line CR LF ) *( "250-" ehlo-line CR LF )
"250" SP ehlo-line CR LF ) "250" SP ehlo-line CR LF )
; the usual HELO chit-chat ; the usual HELO chit-chat
greeting ::= 1*<any character other than CR or LF> greeting ::= 1*<any character other than CR or LF>
ehlo-line ::= ehlo-keyword *( SP ehlo-param ) ehlo-line ::= ehlo-keyword *( SP ehlo-param )
skipping to change at page 5, line 45 skipping to change at page 5, line 4
ALPHA ::= <any one of the 52 alphabetic characters ALPHA ::= <any one of the 52 alphabetic characters
(A through Z in upper case, and, (A through Z in upper case, and,
a through z in lower case)> a through z in lower case)>
DIGIT ::= <any one of the 10 numeric characters DIGIT ::= <any one of the 10 numeric characters
(0 through 9)> (0 through 9)>
CR ::= <the carriage-return character CR ::= <the carriage-return character
(ASCII decimal code 13)> (ASCII decimal code 13)>
LF ::= <the line-feed character LF ::= <the line-feed character
(ASCII decimal code 10)> (ASCII decimal code 10)>
SP ::= <the space character SP ::= <the space character
(ASCII decimal code 32)> (ASCII decimal code 32)>
Although EHLO keywords may be specified in upper, lower, or Although EHLO keywords may be specified in upper, lower, or mixed
mixed case, they must always be recognized and processed in a case, they must always be recognized and processed in a case-
case-insensitive manner. This is simply an extension of insensitive manner. This is simply an extension of practices begun in
practices begun in RFC 821. RFC 821.
The IANA maintains a registry of SMTP service extensions. The IANA maintains a registry of SMTP service extensions. Associated
Associated with each such extension is a corresponding EHLO with each such extension is a corresponding EHLO keyword value. Each
keyword value. Each service extension registered with the IANA service extension registered with the IANA must be defined in an RFC.
must be defined in an RFC. Such RFCs must either be on the Such RFCs must either be on the standards-track or must define an
standards-track or must define an IESG-approved experimental IESG-approved experimental protocol. The definition must include:
protocol. The definition must include:
(1) the textual name of the SMTP service extension; (1) the textual name of the SMTP service extension;
(2) the EHLO keyword value associated with the extension; (2) the EHLO keyword value associated with the extension;
(3) the syntax and possible values of parameters associated (3) the syntax and possible values of parameters associated
with the EHLO keyword value; with the EHLO keyword value;
(4) any additional SMTP verbs associated with the extension (4) any additional SMTP verbs associated with the extension
(additional verbs will usually be, but are not required (additional verbs will usually be, but are not required
skipping to change at page 6, line 35 skipping to change at page 5, line 40
(5) any new parameters the extension associates with the (5) any new parameters the extension associates with the
MAIL FROM or RCPT TO verbs; MAIL FROM or RCPT TO verbs;
(6) how support for the extension affects the behavior of a (6) how support for the extension affects the behavior of a
server and client SMTP; and, server and client SMTP; and,
(7) the increment by which the extension is increasing the (7) the increment by which the extension is increasing the
maximum length of the commands MAIL FROM, RCPT TO, or maximum length of the commands MAIL FROM, RCPT TO, or
both, over that specified in RFC 821. both, over that specified in RFC 821.
In addition, any EHLO keyword value that starts with an upper In addition, any EHLO keyword value that starts with an upper or
or lower case "X" refers to a local SMTP service extension, lower case "X" refers to a local SMTP service extension, which is
which is used through bilateral, rather than standardized, used through bilateral, rather than standardized, agreement. Keywords
agreement. Keywords beginning with "X" may not be used in a beginning with "X" may not be used in a registered service extension.
registered service extension.
Any keyword values presented in the EHLO response that do not Any keyword values presented in the EHLO response that do not begin
begin with "X" must correspond to a standard, standards-track, with "X" must correspond to a standard, standards-track, or IESG-
or IESG-approved experimental SMTP service extension approved experimental SMTP service extension registered with IANA. A
registered with IANA. A conforming server must not offer non conforming server must not offer non "X" prefixed keyword values that
"X" prefixed keyword values that are not described in a are not described in a registered extension.
registered extension.
Additional verbs are bound by the same rules as EHLO keywords; Additional verbs are bound by the same rules as EHLO keywords;
specifically, verbs begining with "X" are local extensions specifically, verbs begining with "X" are local extensions that may
that may not be registered or standardized and verbs not not be registered or standardized and verbs not beginning with "X"
beginning with "X" must always be registered. must always be registered.
4.4. Failure response 4.4. Failure response
If for some reason the server SMTP is unable to list the If for some reason the server SMTP is unable to list the service
service extensions it supports, it will return code 554. extensions it supports, it will return code 554.
In the case of a failure response, the client SMTP should In the case of a failure response, the client SMTP should issue
issue either the HELO or QUIT command. either the HELO or QUIT command.
4.5. Error responses from extended servers 4.5. Error responses from extended servers
If the server SMTP recognizes the EHLO command, but the If the server SMTP recognizes the EHLO command, but the command
command argument is unacceptable, it will return code 501. argument is unacceptable, it will return code 501.
If the server SMTP recognizes, but does not implement, the If the server SMTP recognizes, but does not implement, the EHLO
EHLO command, it will return code 502. command, it will return code 502.
If the server SMTP determines that the SMTP service is no If the server SMTP determines that the SMTP service is no longer
longer available (e.g., due to imminent system shutdown), it available (e.g., due to imminent system shutdown), it will return
will return code 421. code 421.
In the case of any error response, the client SMTP should In the case of any error response, the client SMTP should issue
issue either the HELO or QUIT command. either the HELO or QUIT command.
4.6. Responses from servers without extensions 4.6. Responses from servers without extensions
A server SMTP that conforms to RFC 821 but does not support A server SMTP that conforms to RFC 821 but does not support the
the extensions specified here will not recognize the EHLO extensions specified here will not recognize the EHLO command and
command and will consequently return code 500, as specified in will consequently return code 500, as specified in RFC 821. The
RFC 821. The server SMTP should stay in the same state after server SMTP should stay in the same state after returning this code
returning this code (see section 4.1.1 of RFC 821). The (see section 4.1.1 of RFC 821). The client SMTP may then issue
client SMTP may then issue either a HELO or a QUIT command. either a HELO or a QUIT command.
4.7. Responses from improperly implemented servers 4.7. Responses from improperly implemented servers
Some SMTP servers are known to disconnect the SMTP Some SMTP servers are known to disconnect the SMTP transmission
transmission channel upon receipt of the EHLO command. The channel upon receipt of the EHLO command. The disconnect can occur
disconnect can occur immediately or after sending a response. immediately or after sending a response. Such behavior violates
Such behavior violates section 4.1.1 of RFC 821, which section 4.1.1 of RFC 821, which explicitly states that disconnection
explicitly states that disconnection should only occur after a should only occur after a QUIT command is issued.
QUIT command is issued.
Nevertheless, in order to achieve maxmimum interoperablity it Nevertheless, in order to achieve maxmimum interoperablity it is
is suggested that extended SMTP clients using EHLO be coded to suggested that extended SMTP clients using EHLO be coded to check for
check for server connection closure after EHLO is sent, either server connection closure after EHLO is sent, either before or after
before or after returning a reply. If this happens the client returning a reply. If this happens the client must decide if the
must decide if the operation can be successfully completed operation can be successfully completed without using any SMTP
without using any SMTP extensions. If it can a new connection extensions. If it can a new connection can be opened and the HELO
can be opened and the HELO command can be used. command can be used.
Other improperly-implemented servers will not accept a HELO Other improperly-implemented servers will not accept a HELO command
command after EHLO has been sent and rejected. In some cases, after EHLO has been sent and rejected. In some cases, this problem
this problem can be worked around by sending a RSET after the can be worked around by sending a RSET after the failure response to
failure response to EHLO, then sending the HELO. Clients that EHLO, then sending the HELO. Clients that do this should be aware
do this should be aware that many implementations will return that many implementations will return a failure code (e.g., 503 Bad
a failure code (e.g., 503 Bad sequence of commands) in sequence of commands) in response to the RSET. This code can be
response to the RSET. This code can be safely ignored. safely ignored.
5. Initial IANA Registry 5. Initial IANA Registry
The IANA's initial registry of SMTP service extensions The IANA's initial registry of SMTP service extensions consists of
consists of these entries: these entries:
Service Ext EHLO Keyword Parameters Verb Added Behavior 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 SEND none SEND defined in RFC 821
Send and Mail SAML none SAML defined in RFC 821 Send or Mail SOML none SOML defined in RFC 821
Expand EXPN none EXPN defined in RFC 821 Send and Mail SAML none SAML defined in RFC 821
Help HELP none HELP defined in RFC 821 Expand EXPN none EXPN defined in RFC 821
Turn TURN none TURN 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.)
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 6. MAIL FROM and RCPT TO Parameters
It is recognized that several of the extensions planned for It is recognized that several of the extensions planned for SMTP will
SMTP will make use of additional parameters associated with make use of additional parameters associated with the MAIL FROM and
the MAIL FROM and RCPT TO command. The syntax for these RCPT TO command. The syntax for these commands, again using the ABNF
commands, again using the ABNF notation of [2] as well as notation of [2] as well as underlying definitions from [1], is:
underlying definitions from [1], is:
esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] esmtp-parameter ::= esmtp-keyword ["=" esmtp-value]
esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; syntax and values depend on esmtp-keyword ; syntax and values depend on esmtp-keyword
esmtp-value ::= 1*<any CHAR excluding "=", SP, and all esmtp-value ::= 1*<any CHAR excluding "=", SP, and all
control characters (US ASCII 0-31 control characters (US ASCII 0-31
inclusive)> inclusive)>
; The following commands are extended to ; The following commands are extended to
; accept extended parameters. ; accept extended parameters.
inner-esmtp-cmd ::= ("MAIL FROM:" reverse-path) / inner-esmtp-cmd ::= ("MAIL FROM:" reverse-path) /
("RCPT TO:" forward-path) ("RCPT TO:" forward-path)
All esmtp-keyword values must be registered as part of the All esmtp-keyword values must be registered as part of the IANA
IANA registration process described above. This definition registration process described above. This definition only provides
only provides the framework for future extension; no extended the framework for future extension; no extended MAIL FROM or RCPT TO
MAIL FROM or RCPT TO parameters are defined by this RFC. parameters are defined by this RFC.
6.1. Error responses 6.1. Error responses
If the server SMTP does not recognize or cannot implement one If the server SMTP does not recognize or cannot implement one or more
or more of the parameters associated with a particular MAIL of the parameters associated with a particular MAIL FROM or RCPT TO
FROM or RCPT TO command, it will return code 555. command, it will return code 555.
If for some reason the server is temporarily unable to If for some reason the server is temporarily unable to accomodate one
accomodate one or more of the parameters associated with a or more of the parameters associated with a MAIL FROM or RCPT TO
MAIL FROM or RCPT TO command, and if the definition of the command, and if the definition of the specific parameter does not
specific parameter does not mandate the use of another code, mandate the use of another code, it should return code 455.
it should return code 455.
Errors specific to particular parameters and their values will Errors specific to particular parameters and their values will be
be specified in the parameter's defining RFC. specified in the parameter's defining RFC.
7. Received: Header Field Annotation 7. Received: Header Field Annotation
SMTP servers are required to add an appropriate Received: SMTP servers are required to add an appropriate Received: field to
field to the headers of all messages they receive. A "with the headers of all messages they receive. A "with ESMTP" clause
ESMTP" clause should be added to this field when any SMTP should be added to this field when any SMTP service extensions are
service extensions are used. "ESMTP" is hereby added to the used. "ESMTP" is hereby added to the list of standard protocol names
list of standard protocol names registered with IANA. registered with IANA.
8. Usage Examples 8. Usage Examples
(1) An interaction of the form: (1) An interaction of the form:
S: <wait for connection on TCP port 25> S: <wait for connection on TCP port 25>
C: <open connection to server> C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu C: EHLO ymir.claremont.edu
S: 250 dbc.mtview.ca.us says hello S: 250 dbc.mtview.ca.us says hello
skipping to change at page 11, line 20 skipping to change at page 9, line 42
... ...
The 500 response indicates that the server SMTP does The 500 response indicates that the server SMTP does
not implement the extensions specified here. The not implement the extensions specified here. The
client would normally send a HELO command and proceed client would normally send a HELO command and proceed
as specified in RFC 821. See section 4.7 for as specified in RFC 821. See section 4.7 for
additional discussion. additional discussion.
9. Security Considerations 9. Security Considerations
This RFC does not discuss security issues and is not believed This RFC does not discuss security issues and is not believed to
to raise any security issues not already endemic in electronic raise any security issues not already endemic in electronic mail and
mail and present in fully conforming implementations of RFC- present in fully conforming implementations of RFC-821. It does
821. It does provide an announcement of server mail provide an announcement of server mail capabilities via the response
capabilities via the response to the EHLO verb. However, all to the EHLO verb. However, all information provided by announcement
information provided by announcement of any of the initial set of any of the initial set of service extensions defined by this RFC
of service extensions defined by this RFC can be readily can be readily deduced by selective probing of the verbs required to
deduced by selective probing of the verbs required to transport and deliver mail. The security implications of service
transport and deliver mail. The security implications of extensions described in other RFCs should be dealt with in those
service extensions described in other RFCs should be dealt RFCs.
with in those RFCs.
10. Acknowledgements 10. Acknowledgements
This document represents a synthesis of the ideas of many This document represents a synthesis of the ideas of many people and
people and reactions to the ideas and proposals of others. reactions to the ideas and proposals of others. Randall Atkinson,
Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
Vaudreuil contributed ideas and text sufficient to be and text sufficient to be considered co-authors. Other important
considered co-authors. Other important suggestions, text, or suggestions, text, or encouragement came from Harald Alvestrand, Jim
encouragement came from Harald Alvestrand, Jim Conklin, Mark Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan
Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan Zachariassen, and the contributions of the entire IETF SMTP Working
Zachariassen, and the contributions of the entire IETF SMTP Group. Of course, none of the individuals are necessarily responsible
Working Group. Of course, none of the individuals are for the combination of ideas represented here. Indeed, in some cases,
necessarily responsible for the combination of ideas the response to a particular criticism was to accept the problem
represented here. Indeed, in some cases, the response to a identification but to include an entirely different solution from the
particular criticism was to accept the problem identification one originally proposed.
but to include an entirely different solution from the one
originally proposed.
11. References 11. References
[1] J.B. Postel. Simple Mail Transfer Protocol. Request for [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
Comments 821, (August, 1982). USC/Information Sciences Institute, August 1982.
[2] D.H. Crocker. Standard for the Format of ARPA Internet [2] Crocker, D., "Standard for the Format of ARPA Internet Text
Text Messages. Request for Comments 822, (August, 1982). Messages", STD 11, RFC 822, UDEL, August 1982.
[3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions. Request for Comments 1521, (September, Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
1993).
[4] K. Moore. Representation of Non-ASCII Text in Internet [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
Message Headers. Request for Comments 1522, (September, Headers", RFC 1522, University of Tennessee, September 1993.
1993).
[5] R.T. Braden. Requirements for Internet Hosts - [5] Braden, R., "Requirements for Internet Hosts - Application and
Application and Support. Request for Comments 1123, Support", STD 3, RFC 1123, USC/Information Sciences Institute,
(October, 1989). October 1989.
12. Chair, Editor, and Author Addresses 12. Chair, Editor, and Author Addresses
John Klensin, WG Chair John Klensin, WG Chair
MCI MCI
2100 Reston Parkway 2100 Reston Parkway
Reston, VA 22091 Reston, VA 22091
tel: +1 703 715-7361 fax: +1 703 715-7436
email: klensin@mci.net
Ned Freed, Editor Phone: +1 703 715-7361
Innosoft International, Inc. Fax: +1 703 715-7436
1050 East Garvey Avenue South EMail: klensin@mci.net
West Covina, CA 91790 Ned Freed, Editor
USA Innosoft International, Inc.
tel: +1 818 919 3600 fax: +1 818 919 3614 1050 East Garvey Avenue South
email: ned@innosoft.com West Covina, CA 91790
USA
Marshall T. Rose Phone: +1 818 919 3600
Dover Beach Consulting, Inc. Fax: +1 818 919 3614
420 Whisman Court EMail: ned@innosoft.com
Moutain View, CA 94043-2186
USA
tel: +1 415 968 1052 fax: +1 415 968 2510
email: mrose@dbc.mtview.ca.us
Einar A. Stefferud Marshall T. Rose
Network Management Associates, Inc. Dover Beach Consulting, Inc.
17301 Drey Lane 420 Whisman Court
Huntington Beach, CA, 92647-5615 Moutain View, CA 94043-2186
USA USA
tel: +1 714 842 3711 fax: +1 714 848 2091
email: stef@nma.com
Dave Crocker Phone: +1 415 968 1052
Brandenburg Consulting Fax: +1 415 968 2510
675 Spruce Dr. EMail: mrose@dbc.mtview.ca.us
Sunnyvale, CA 94086 USA
USA Einar A. Stefferud
tel: +1 408 246 8253 fax: +1 408 249 6205 Network Management Associates, Inc.
email: dcrocker@mordor.stanford.edu 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
 End of changes. 61 change blocks. 
294 lines changed or deleted 258 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/