As per Relevance of the word extension, we have this rfc below:
Network Working Group N.
Request for Comments: 2197
Obsoletes: 1854 September 1997
Category: Standards
SMTP Service
for Command
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 an extension to the SMTP service whereby a
can indicate the extent of its ability to accept multiple commands
a single TCP send operation. Using a single TCP send operation
multiple commands can improve SMTP performance significantly
The present document is an updated version of RFC 1854 [3].
textual and editorial changes have been made; the protocol has
changed in any way
2.
Although SMTP is widely and robustly deployed, certain extensions
nevertheless prove useful. In particular, many parts of the
make use of high latency network links. SMTP's intrinsic
command-one response structure is significantly penalized by
latency links, often to the point where the factors contributing
overall connection time are dominated by the time spent waiting
responses to individual commands (turnaround time).
In the best of all worlds it would be possible to simply deploy
client software that makes use of command pipelining: batching
multiple commands into single TCP send operations. Unfortunately,
original SMTP specification [1] did not explicitly state that
servers must support this. As a result a non-trivial number
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
the SMTP dialogue. Creation of server processes
incoming SMTP connections is a useful, obvious,
harmless implementation technique. However, some
servers defer process forking and connection
until some intermediate point in the SMTP dialogue
When this is done material read from the TCP
and kept in process buffers can be lost
(2) Flushing the TCP input buffer when an SMTP
fails. SMTP commands often fail but there is no
to flush the TCP input buffer when this happens
Nevertheless, some SMTP servers do this
(3) Improper processing and promulgation of SMTP
failures. For example, some SMTP servers will refuse
accept a DATA command if the last RCPT TO
fails, paying no attention to the success or failure
prior RCPT TO command results. Other servers
accept a DATA command even when all previous RCPT
commands have failed. Although it is possible
accommodate this sort of behavior in a client
employs command pipelining, it does complicate
construction of the client unnecessarily
This memo uses the mechanism described in [2] to define an
to the SMTP service whereby an SMTP server can declare that it
capable of handling pipelined commands. The SMTP client can
check for this declaration and use pipelining only when the
declares itself capable of handling it
2.1. Requirements
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
requirements of this specification. A discussion of the meanings
these terms appears in RFC 2119 [4].
3. Framework for the Command Pipelining
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
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
FROM or RCPT TO commands
(5) no additional SMTP verbs are defined by this extension
and
(6) the next section specifies how support for
extension affects the behavior of a server and
SMTP
4. The Pipelining Service
When a client SMTP wishes to employ command pipelining, it
issues the EHLO command to the server SMTP. If the server
responds with code 250 to the EHLO command, and the response
the EHLO keyword value PIPELINING, then the server SMTP has
that it can accommodate SMTP command pipelining
4.1. Client use of
Once the client SMTP has confirmed that support exists for
pipelining extension, the client SMTP may then elect to
groups of SMTP commands in batches without waiting for a response
each individual command. In particular, the commands RSET, MAIL FROM
SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear
in a pipelined command group. The EHLO, DATA, VRFY, EXPN, TURN
QUIT, and NOOP commands can only appear as the last command in
group since their success or failure produces a change of state
the client SMTP must accommodate. (NOOP is included in this group
it can be used as a synchronization point.)
Additional commands added by other SMTP extensions may only appear
the last command in a group unless otherwise specified by
extensions that define the commands
The actual transfer of message content is explicitly allowed to
the first "command" in a group. That is, a RSET/MAIL FROM
used to initiate a new message transaction can be placed in the
group as the final transfer of the headers and body of the
message
Client SMTP implementations that employ pipelining MUST check
statuses associated with each command in a group. For example,
none of the RCPT TO recipient addresses were accepted the client
Freed Standards Track [Page 3]
RFC 2197 SMTP Service Extension September 1997
then check the response to the DATA command -- the client
assume that the DATA command will be rejected just because none
the RCPT TO commands worked. If the DATA command was
rejected the client SMTP can just issue RSET, but if the DATA
was accepted the client SMTP should send a single dot
Command statuses MUST be coordinated with responses by counting
separate response and correlating that count with the number
commands known to have been issued. Multiline responses MUST
supported. Matching on the basis of either the error code value
associated text is expressly forbidden
Client SMTP implementations MAY elect to operate in a
fashion, processing server responses immediately upon receipt,
if there is still data pending transmission from the client'
previous TCP send operation. If nonblocking operation is
supported, however, client SMTP implementations MUST also check
TCP window size and make sure that each group of commands
entirely within the window. The window size is usually, but
always, 4K octets. Failure to perform this check can lead
deadlock conditions
Clients MUST NOT confuse responses to multiple commands
multiline responses. Each command requires one or more lines
response, the last line not containing a dash between the
code and the response string
4.2. Server support of
A server SMTP implementation that offers the pipelining extension
(1) MUST NOT flush or otherwise lose the contents of
TCP input buffer under any circumstances whatsoever
(2) SHOULD issue a positive response to the DATA command
and only if one or more valid RCPT TO addresses
been previously received
(3) MUST NOT, after issuing a positive response to a
command with no valid recipients and
receiving an empty message, send any message
to anybody
(4) SHOULD elect to store responses to grouped RSET,
FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT
commands in an internal buffer so they can sent as
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
the local TCP input buffer is emptied
(8) MUST NOT make assumptions about commands that are
to be received
(9) SHOULD issue response text that indicates,
implicitly or explicitly, what command the
matches
The overriding intent of these server requirements is to make it
easy as possible for servers to conform to these
extensions
5.
Consider the following SMTP dialogue that does not use pipelining
S: connection
C: connection to server
S: 220 innosoft.com SMTP service
C: HELO dbc.mtview.ca.
S: 250 innosoft.
C: MAIL FROM:
S: 250 sender
C: RCPT TO:
S: 250 recipient
C: RCPT TO:
S: 250 recipient
C: RCPT TO:
S: 250 recipient
C:
S: 354 enter mail, end with line containing only "."
...
C: .
S: 250 message
C:
S: 221
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
simple example. But if pipelining is employed the following
is possible
S: connection
C: connection to server
S: 220 innosoft.com SMTP service
C: EHLO dbc.mtview.ca.
S: 250-innosoft.
S: 250
C: MAIL FROM:
C: RCPT TO:
C: RCPT TO:
C: RCPT TO:
C:
S: 250 sender
S: 250 recipient
S: 250 recipient
S: 250 recipient
S: 354 enter mail, end with line containing only "."
...
C: .
C:
S: 250 message
S: 221
The total number of turnarounds has been reduced from 9 to 4.
The next example illustrates one possible form of behavior
pipelining is used and all recipients are rejected
S: connection
C: connection to server
S: 220 innosoft.com SMTP service
C: EHLO dbc.mtview.ca.
S: 250-innosoft.
S: 250
C: MAIL FROM:
C: RCPT TO:
C: RCPT TO:
C:
S: 250 sender
S: 550 remote mail to not
S: 550 remote mail to not
S: 554 no valid recipients
C:
S: 221
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
server SMTP does not check for at least one valid recipient prior
accepting the DATA command, the following dialogue would result
S: connection
C: connection to server
S: 220 innosoft.com SMTP service
C: EHLO dbc.mtview.ca.
S: 250-innosoft.
S: 250
C: MAIL FROM:
C: RCPT TO:
C: RCPT TO:
C:
S: 250 sender
S: 550 remote mail to not
S: 550 remote mail to not
S: 354 enter mail, end with line containing only "."
C: .
C:
S: 554 no valid
S: 221
6. Security
This document does not discuss security issues and is not believed
raise any security issues not endemic in electronic mail and
in fully conforming implementations of [1].
7.
This document is based on the SMTP service extension model
in RFC 1425. Marshall Rose's description of SMTP command
in his book "The Internet Message" also served as a source
inspiration for this extension
8.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[2] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
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
Requirement Levels", RFC 2119, March 1997.
9. Author's
Ned
Innosoft International, Inc
1050 Lakes
West Covina, CA 91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.
This document is a product of work done by the Internet
Task Force Working Group on Messaging Extensions, Alan Cargille
chair
Freed Standards Track [Page 8]
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
